Week 3.5: 고가용성 및 확장성 아키텍처

Multi-AZ, Auto Scaling, Load Balancer를 활용한 99.9% 가용성을 가진 엔터프라이즈급 웹 서비스

아키텍처 개요

인터넷 사용자
    ↓
Application Load Balancer (Multi-AZ)
    ↓
VPC (10.0.0.0/16)
├── ap-northeast-2a (가용영역 A)
│   ├── Public Subnet (10.0.1.0/24)
│   │   └── Web Server (Apache) - Auto Scaling
│   └── Private Subnet (10.0.2.0/24)
│       └── WAS Server (Tomcat)
├── ap-northeast-2c (가용영역 C)
│   ├── Public Subnet (10.0.3.0/24)
│   │   └── Web Server (Apache) - Auto Scaling
│   └── Private Subnet (10.0.4.0/24)
│       └── WAS Server (Tomcat)
└── RDS Multi-AZ MySQL
    ├── Primary (ap-northeast-2a)
    └── Standby (ap-northeast-2c)

고가용성 설계 원칙

1. 무결점 운영 (Zero Single Point of Failure)

모든 구성 요소가 이중화:
├── ALB: 2개 가용영역에 자동 배치
├── Web Server: 각 AZ에 최소 1대씩
├── WAS Server: 각 AZ에 최소 1대씩
└── Database: Primary + Standby

2. 자동 장애 복구

장애 감지 및 복구:
├── Health Check: 30초마다 상태 확인
├── Auto Scaling: 불건전 인스턴스 자동 교체
├── ALB: 장애 서버로 트래픽 중단
└── RDS: 자동 Failover (60초 이내)

3. 탄력적 확장

부하에 따른 자동 조절:
├── CPU 70% 이상: 서버 추가 생성
├── CPU 30% 이하: 서버 자동 제거
├── 최소 용량: 2대 (각 AZ 1대씩)
└── 최대 용량: 8대 (각 AZ 4대씩)

핵심 구성 요소

1. Application Load Balancer (ALB)

ALB: webapp-alb
├── Scheme: Internet-facing
├── IP address type: IPv4
├── Availability Zones:
│   ├── ap-northeast-2a (10.0.1.0/24)
│   └── ap-northeast-2c (10.0.3.0/24)
├── Security Group: webapp-alb-sg
├── Target Group: webapp-web-tg
└── Health Check: /webapp/health.html

2. Auto Scaling Group

Auto Scaling Group: webapp-web-asg
├── Launch Template: webapp-web-template
├── Min Size: 2 (각 AZ 최소 1대)
├── Desired Size: 2
├── Max Size: 8
├── Health Check Type: ELB + EC2
└── Scaling Policies:
    ├── Scale Up: CPU > 70%
    └── Scale Down: CPU < 30%

3. Multi-AZ RDS

RDS: webapp-db
├── Engine: MySQL 8.0
├── Multi-AZ: Enabled
├── Primary: ap-northeast-2a
├── Standby: ap-northeast-2c
└── Auto Failover: 60-120초

장애 복구 시나리오

웹 서버 1대 장애

1. ALB Health Check 실패 감지 (150초)
2. 해당 인스턴스로 트래픽 중단
3. Auto Scaling이 새 인스턴스 시작
4. 새 인스턴스 헬스 체크 통과
5. 트래픽 분산 재개

서비스 영향: 없음
복구 시간: 5-8분

가용영역 전체 장애

1. ap-northeast-2a 전체 장애
2. ALB가 2c AZ로만 트래픽 전달
3. Auto Scaling이 2c에서 인스턴스 추가
4. RDS Primary → Standby 자동 Failover

서비스 영향: 일시적 성능 저하
복구 시간: 2-5분

성능 비교

Week 3 vs Week 3.5

Week 3 (단일 인스턴스):
├── 동시 접속: ~300명
├── 응답 시간: 200ms
├── 처리량: ~200 req/sec
└── 가용성: 95%

Week 3.5 (HA + Auto Scaling):
├── 동시 접속: ~1,000명+
├── 응답 시간: 150ms
├── 처리량: ~800 req/sec
└── 가용성: 99.9%

비용 최적화

탄력적 비용 구조

최소 구성 (새벽):
├── Web Server: 2대
├── 월 비용: ~$80

최대 구성 (피크):
├── Web Server: 8대
├── 월 비용: ~$200 (일시적)

평균 비용: ~$120/월
비용 효율성: 300% 향상

Week 4로의 발전

추가할 영역

모니터링:
├── CloudWatch 대시보드
├── 알람 및 알림 체계
├── 성능 분석
└── 비용 분석

최적화:
├── 성능 튜닝
├── 보안 강화
├── 비용 최적화
└── 운영 자동화

Week 3.5 완성: 절대 죽지 않는 고가용성 웹 서비스 구축 완료
다음 단계: AWS EDU/Archive/조선대학교 AWS 멘토링/Edu Architecture/Week4-Operations-Architecture - 통합 모니터링 및 운영 최적화